Many communication networks employ architectures commonly referred to as host-remote architectures. In such architectures, a host device is typically connected to several remote devices, which are in turn connected to one or more devices at subscriber premises. Host-remote architectures are able to provide network access at many geographic locations while also minimizing equipment and operation costs by centralizing certain network functions at host devices. Remote devices do not require all of the equipment implemented in host devices because, during normal operations, remote devices depend on host devices for certain operations and information. For example, host devices often maintain routing information used by remote devices to make routing decisions.
On occasion, however, a remote device may be unable to communicate with its corresponding host device. For example, connectivity between the remote device and the host device may be lost, or the host device may fail. Because of the chance of becoming isolated from a host device, and consequently from the rest of the communication network, certain remote devices have been configured to operate in what is commonly referred to as Emergency Standalone (“ESA”) mode when isolated from a host device. In ESA mode, a remote device may be configured to take over control of routing functions. However, because the connection (e.g., a trunk line) to the host device is unavailable, communications can generally be routed only to lines connected directly to the remote device (i.e., local lines).
When a remote device is in ESA mode, subscribers connected to the remote device will not be able to complete communications that require use of the connection between the remote device and its host device. This scenario is especially troublesome for emergency “911” communications that would normally be routed through the connection to the host device. A person initiating a 911 communication may get no more than a fast busy signal. Clearly, such a condition may be catastrophic to any person in need of immediate emergency assistance.
Several attempts have been made to make 911 services reachable during ESA mode. For example, certain remote devices have been configured to forward 911 communications directly to local emergency service providers (e.g., local police or fire departments having communication devices served by the remote devices). However, this type of solution requires emergency service providers to have an emergency telephone number and device, as well as one or more persons continuously monitoring the telephone device. The persons may also have to undergo training related to answering incoming 911 communications. Consequently, local forwarding of 911 communications directly to emergency service providers is an expensive and rudimentary solution.
In addition, local forwarding of emergency 911 communications does not provide access to full 911 services. For example, automatic location identification (“ALI”) information is not provided along with locally forwarded emergency communications. Unfortunately, the absence of ALI information can delay emergency response actions. Moreover, local forwarding of an emergency communication to a local public safety answering point (“PSAP”) may be suitable in some circumstances, such as when the location of a communication initiator happens to be within the geographical area served by the local PSAP to which the communication is forwarded. However, this is not a suitable solution when the location of the communication initiator is not served by the locally available PSAP. In such instances, access to full 911 services is desired so that appropriate PSAPs can be identified based on locations of initiators of emergency communications and so that ALI information can be provided to the PSAPs receiving emergency communications.
Other existing solutions also have shortcomings. For example, certain solutions are vendor specific. That is, the solutions are designed for specific equipment and therefore require network operators using other types of equipment to purchase different and expensive equipment from a particular vendor. Accordingly, vendor-specific solutions are not practical solutions for many deployed communication networks.
Yet other existing solutions work only for specific types of communications and are incompatible with other communication types and formats. For example, certain existing solutions are designed for Time Division Multiplexing (“TDM”) communication signals but do not work for Voice over Internet Protocol (“VoIP”) communication signals. Accordingly, the existing state of the art does not include a widely compatible and cost-effective solution for routing emergency 911 communications to full 911 services when in ESA mode.